Client Design Pattern alias NAMING SERVICE ****************************************** A Miro Client (aka consumer) polls data from a Miro Server (aka supplier). The communication is point-to-point. The Server usually registers ("binds" its name) to the Name Service and starts publishing data in response to the requests made by the Client. The Client finds the Server by its registered name on the Name Service (it "resolves" the server name). The Naming Service should be running at start-up on every MIRO machine. ! When destroying the Naming Service, existing connections between objects PERSIST ! Publish-Subscribe Design Pattern alias EVENT SERVICE **************************************************** An Event Channel is created and registered to a Name Service. Objects act as suppliers and consumers by publishing events and subscribing to events. The communication is 1-to-n. Suppliers raise events to the Event Channel, while consumers counsume events from the Event Channel. There is complete communication transparency (there is no direct connection between the objects; the Event Channel decouples them). Very scalable pattern. A server can also be created using an ACE Reactor timer event, so that it creates events at a user defined interval. There are 2 models : -> PUSH (the supplier initiates the communication by supplying the data to the event channel) -> the supplier calls PushSupplier() each time it wants to put data on the event channel -> whenever an event of interest occurs, the event channel, through the event service, invokes PushConsumer() (defined on the consumer) and so it pushes data to the consumer -> PULL (the consumer inititiates the communication by requesting data from the event channel) ! When destroying the Event Service, existing connections between objects ARE DESTROYED ! NOTIFICATION SERVICE ********************* ! The Notification Service is backward compatible with the Event Service ! Suppliers and consumers specify what events they provide / would like to consume. Instead of addressing other objects by their name, objects are now calling the Notification Service for data that suits a specific need (a desired event type, data sequence, etc.) The difference from the Event Service is that in the Event Service the events published by a supplier are passed to all connected consumers, while in the Notification Service only the events that are needed by consumers are passed to them accordingly (the communication is n-to-n). An Event Service is usually built for each service provided by the suppliers, while the Notification Service can handle a multitude of such events.